To avoid this we’ve changed iOS 14.0b7 and later to be more forgiving in this case (r. 66931425). If you must use a file lock, make sure to release it before you become eligible for suspension. I wonder how "future-proof" this forgiving treatment is. Thing is, I'm using file locks in a bit of inconventional way: to find out which processes in the same app group are actually alive. It works like this: When a process (a main app, share extension, etc.) starts, it obtains a unique "virtual process ID" from a shared SQLite DB, creates a file with that ID in a shared app container and puts a file lock on it. This virtual PID is used a key/token to put a temporary modification protection on shared virtual resources (basically, files in a shared VFS). When other process wants such resource and "sees" that it is protected by some other VPID, it can query VPID DB and/or relevant VPID file's lock to see if such process still actually exist and still wants the resource for itself. If process (e.g. a share extension) have finished normally, it will simply delete it's VPID file (raising a file lock along the way) and DB record; if it was abruptly terminated by the OS, the DB record will stay, but the file lock will be raised automagically. As you can see, this use case would not produce any deadlocks (since lock on a each file is put exactly once and only queried afterwards), but totally relies on ability to hold file locks in background. So, I wonder how valid/future-proof is that.